New MAME release

[+dhe]

Right, I get that part. The problem is, the IDE card I have doesn't work when plugged in to a geneve + MEMEX512K card expansion. @Shift838 isn't sure why. I was hoping to know if @mizapf while working one this:

   1) tested with a real card and update the emulation.

   2) looked at the schematics and coded according to that  -or-

   3) knew how the software should work logically and made it work.

[Gary from OPA]

1 hour ago, dhe said:

Right, I get that part. The problem is, the IDE card I have doesn't work when plugged in to a geneve + MEMEX512K card expansion. @Shift838 isn't sure why. I was hoping to know if @mizapf while working one this:

   1) tested with a real card and update the emulation.

   2) looked at the schematics and coded according to that  -or-

   3) knew how the software should work logically and made it work.

Which IDE card do you have? Is there current schematics for it?

 

Ok, does your geneve have the genmod as well? Because if it doesn't could be why there is issues.

 

Quote

. For the card to work properly with the Myarc "Geneve", it is necessary to further decode five extra address lines: AMA (pin #46 of the PE-box bus), AMB (pin #45), AMC (pin #48), AMD (pin #8, for use with Genmod) and AME (pin #9, Genmod).

Note that , if you have a Geneve but did not perform the "Genmod" modification, you will need to pull line AMD low and line AME high. This can be done easily by installing two extra 4.7 Kohms resistors. These resistors will make your PE-box GenMod-like, so if you have other cards with similar decoding logic (e.g. my USB-SM card), you will not need to pull AMD nor AME on these cards: one card is enough. If you do have GenMod, you do not need to install these two resistors.

That what AMD and AME are about.

Edited August 10 by Gary from OPA

[+dhe]

    The system I'm running consists of a non-genmod geneve. I am using Shift838's new IDE card, it doesn't like it (instant lockup), when a 512k memex card is inserted.

 

    Shift838 and I did verify, the dip switch on the memex card are correctly set to run as a non-genmod - 512K memory card.

 

    Shift838 built the card from tracing out an original and studying the ASCII schematics on Thierry's website.

 

    So, we have a mystery, maybe the programming note might shed some light.  At one time Ksarul was looking at cloning the Memex memory card, but it's been a while.

[Gary from OPA]

23 minutes ago, dhe said:

    The system I'm running consists of a non-genmod geneve. I am using Shift838's new IDE card, it doesn't like it (instant lockup), when a 512k memex card is inserted.

 

    Shift838 and I did verify, the dip switch on the memex card are correctly set to run as a non-genmod - 512K memory card.

 

    Shift838 built the card from tracing out an original and studying the ASCII schematics on Thierry's website.

 

    So, we have a mystery, maybe the programming note might shed some light.  At one time Ksarul was looking at cloning the Memex memory card, but it's been a while.

Sadly, the IDE card is the only card I still need to get, maybe next month I can afford to buy one.

 

Anyway, as I mentioned in my previous posts that MAME note is to do with the extra two address lines, and I quoted the section from the original designer website page were he mentions that two extra resistors are needed if you don't have a genmod geneve.

 

https://www.unige.ch/medecine/nouspikel/ti99/ide2.htm

 

As you can see in the attached schematic. Maybe you can verify by looking at your card or we have to wait on Shift838 to chime in here.

 

 

[+dhe]

Thanks Gary. I think @Shift838 felt pretty alone on troubleshooting this issue.

 

I think @mizapf got a moral boost to deal with the tipi quirk when @jedimatt42 got involved.

 

Working on your own is very hard.

[+mizapf]

So if you are using Windows, and you would like to build MAME by yourself (e.g. doing some tests or assisting in bug hunting), I set up some - hopefully - useful script files to make it as simple as possible for you.

 

Have a look at the page https://www.ninermame.org/setup/building/winbuild

 

It describes how to install MSYS2 on your Windows system, how to download the MAME sources, and how to build it. Additionally, when you scroll further down, you should find some script files that automate the process described above. It does make sense to get familiar with the details as mentioned in the preceding paragraphs (because I believe that blindly running script files is a real proof of trust, but not always justified).

 

The whole process should not take more than a few minutes. The longest time is the cloning of the MAME repository from Github.

 

If you later decide that building MAME is not your chosen destiny, you can simply uninstall MSYS2, and it will roll back away everything that you installed, except for the MAME installation directory.

 

Please share your experiences with me, so that I can further improve the process.

[+9640News]

Followed all the directions.  When i got to the maketi, I get a message Python is not available to path. Stop.

 

[+mizapf]

Did you really include mingw-w64-x86_64-python?

 

Try pacman -S mingw-w64-x86_64-python and build again.

 

 

[+9640News]

10 hours ago, mizapf said:

Did you really include mingw-w64-x86_64-python?

 

Try pacman -S mingw-w64-x86_64-python and build again.

 

 

I tried it again and it noted it was reinstalling the package.  Then, got the same message Python is not available in path and then it stopped.

[+dhe]

@mizapf - when running mame in ti-99 mode. How can I simulate removing the module, while keeping the emulation running?

   As instructed to do in the software manual that comes with the pgram.

Thanks!

[+mizapf]

8 hours ago, dhe said:

@mizapf - when running mame in ti-99 mode. How can I simulate removing the module, while keeping the emulation running?

   As instructed to do in the software manual that comes with the pgram.

You open the OSD menu (ScrlLock, TAB), then in the "File Manager" you select "cartridge" and there, "empty slot".

[+mizapf]

22 hours ago, 9640News said:

I tried it again and it noted it was reinstalling the package.  Then, got the same message Python is not available in path and then it stopped.

I suppose you see something like a command prompt

 

User@host MINGW64 ~

$ |

 

1. Enter "python". If it does not start, then enter "echo $PATH" and tell me what you got.

2. Enter "/mingw64/bin/python". Exit with "quit()".

[+9640News]

11 hours ago, mizapf said:

I suppose you see something like a command prompt

 

User@host MINGW64 ~

$ |

 

1. Enter "python". If it does not start, then enter "echo $PATH" and tell me what you got.

2. Enter "/mingw64/bin/python". Exit with "quit()".

[+mizapf]

You're in the wrong command line window. It should read "Admin@DellXPS MINGW64 ~".

 

When you search in the Windows menu, look out for "MINGW64", not for "MSYS2". The point is that there are several variants of the MSYS2 shell with different environment settings, including the PATH.

 

Edit: I shall add that note to my recipe on Ninermame.

[+9640News]

OK, I got everything to work.  I still do not have a good handle where the scripts should saved as I put everything in the "admin" folder however mingw64 could not find them.  is there supposed to be a file extension? all lowercase filename?

 

Either way, I was able to build mame.  I did some testing with the tipi and was able to read all the messages on Heatwave on a telnet connection without any issues.  I was then able to copy all the MDOS source files from the TIPI to a HRD image while emulating the Geneve without any problems.  Both items, I could have never been able to do previously.

 

Beery

[+mizapf]

Another thing I should mention for those not too familiar with Unix systems: If you want to run something in the current directory, put a ./ before it:

 

./maketi
./mameprep_msys2

 

File name extensions do not exist in Unix; the period (.) is simply a valid file name character. File names are case-sensitive.

 

Under Windows, I install MAME in C:\prg\mame. The home directory of MSYS2 is C:\msys64\home\michael, and I have the MAME source tree in C:\msys64\home\michael\mamegit\mame.

 

The reason why I do not start MAME from that MAME directory is that a) I want to decouple building from running (if building fails, you may lose your previously working executable) and b) there are lots of other files you want to install in the MAME directory, and git will list all those files as unknown.

[+mizapf]

MAME 0.269

 

Changes for us:

- Fixed TIPI access instabilities

- Fixed debugger issues with TI-99/4P (SGCPU)

 

Links to the pre-built binaries (in case you did not already build MAME by yourself as explained above):

 

- Linux: https://ftp.whtech.com/emulators/MAME/ti99/linux/mame0269b_ti99_linux64bit.tar.gz

- Windows: https://ftp.whtech.com/emulators/MAME/ti99/windows/mame0269b_ti99_win64bit.zip

- Raspberry Pi OS: https://ftp.whtech.com/emulators/MAME/ti99/rpios/mame0269b_ti99_rpios64bit.tar.gz

- macOS: https://ftp.whtech.com/emulators/MAME/full/macos/mame0269b_macos64bit_arm64.zip

[+dhe]

 

Hi, 

  I always check to verify mame is running before doing an upgrade. 

  I started mame and verified all drives with version 266.

 

  Then I upgraded to version 269. 269 fails to run for me. OSLOG before and after. 

 

266   

D:\mame>gmtipi.bat

D:\mame>mame genmod -window -oslog -bios 1.00 -peb:slot3 horizon -peb:slot6 tipi -conn rpi.192.168.2.226 -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -peb:slot8:hfdc:h2 generic -peb:slot8:hfdc:h3 generic -peb:slot8:hfdc:f3 525dd -peb:slot8:hfdc:f4 525dd -hard1 genos7boot.HD -hard2 Bootdisk2.HD -hard3 Bootdisk3.HD -flop1 DM1000SRC.dsk -flop2 DSDD2.hfe -flop3 DSDD3.dsk -flop4 DSDD4.dsk
[:maincpu] Variant = standard (with on-chip RAM), Overflow int = no check
[:peb] AMA/B/C address prefix set to 00000
[:peb] Slot 2 = :peb:slot2:memex
[:peb] Slot 3 = :peb:slot3:horizon
[:peb] Slot 4 = empty
[:peb] Slot 5 = empty
[:peb] Slot 6 = :peb:slot6:tipi
[:peb] Slot 7 = empty
[:peb] Slot 8 = :peb:slot8:hfdc
[:peb:slot8:hfdc:h1:generic] CHD metadata: CYLS:615,HEADS:4,SECS:32,BPS:256
[:peb:slot8:hfdc:h1:generic] Set encoding to 1
[:peb:slot8:hfdc:h1:generic] CHD image has geometry cyl=615, head=4, 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.82 ms, step: 184 us
[:peb:slot8:hfdc:h2:generic] CHD metadata: CYLS:1024,HEADS:16,SECS:32,BPS:256
[:peb:slot8:hfdc:h2:generic] Set encoding to 1
[:peb:slot8:hfdc:h2:generic] CHD image has geometry cyl=1024, head=16, sect=32, size=256
[:peb:slot8:hfdc:h2:generic] MFM HD rec specs: interleave=4, cylskew=0, headskew=0, wpcom=-1, rwc=-1
[:peb:slot8:hfdc:h2:generic] MFM HD gap specs: gap1=16, gap2=3, gap3=18, sync=13, headerlen=5, ecctype=-1
[:peb:slot8:hfdc:h2:generic] Calculated settle time: 9.81 ms, step: 190 us
[:peb:slot8:hfdc:h3:generic] CHD metadata: CYLS:1024,HEADS:16,SECS:32,BPS:256
[:peb:slot8:hfdc:h3:generic] Set encoding to 1
[:peb:slot8:hfdc:h3:generic] CHD image has geometry cyl=1024, head=16, sect=32, size=256
[:peb:slot8:hfdc:h3:generic] MFM HD rec specs: interleave=4, cylskew=0, headskew=0, wpcom=-1, rwc=-1
[:peb:slot8:hfdc:h3:generic] MFM HD gap specs: gap1=16, gap2=3, gap3=18, sync=13, headerlen=5, ecctype=-1
[:peb:slot8:hfdc:h3:generic] Calculated settle time: 9.81 ms, step: 190 us
Input: Dropping invalid input token JOYCODE_3_UNKNOWN_SWITCH
Input: Dropping invalid input token GUNCODE_3_UNKNOWN_SWITCH
Input: Dropping invalid input token JOYCODE_3_UNKNOWN_SWITCH
Soft reset
[:peb:slot2:memex] memex dips = 01
[:peb:slot3:horizon] Horizon card memory: 2097152 bytes
[:peb:slot6:tipi] Trying to connect to Raspberry Pi at 192.168.2.226:9901/tipi
[:peb:slot8:hfdc] FD connector f1 with 5.25" double density floppy drive
[:peb:slot6:tipi] Connection established
[:peb:slot8:hfdc] FD connector f2 with 5.25" double density floppy drive
[:peb:slot6:tipi] TIPI server offers ASYNC communication
[:peb:slot8:hfdc] FD connector f3 with 5.25" double density floppy drive
[:peb:slot8:hfdc] FD connector f4 with 5.25" double density floppy drive
[:peb:slot8:hfdc] HD connector h1 with Generic MFM hard disk
[:peb:slot8:hfdc] HD connector h2 with Generic MFM hard disk
[:peb:slot8:hfdc] HD connector h3 with Generic MFM hard disk
[:] Video RAM set to 192 KiB
[:maincpu] RESET; automatic wait state creation is disabled
[:kbd:geneve_kb_101] Reset triggered
[:] Keyboard reset (line not connected)
[:kbd:geneve_kb_101] Reset triggered
[:peb:slot8:hfdc:h1:generic] Spinup complete, drive recalibrated and positioned at cylinder 0; drive is READY
[:peb:slot8:hfdc:h2:generic] Spinup complete, drive recalibrated and positioned at cylinder 0; drive is READY
[:peb:slot8:hfdc:h3:generic] Spinup complete, drive recalibrated and positioned at cylinder 0; drive is READY
[:peb:slot6:tipi] Closing connection
[:peb:slot6:tipi] Trying to connect to Raspberry Pi at 192.168.2.226:9901/tipi
[:peb:slot6:tipi] Connection established
[:peb:slot6:tipi] TIPI server offers ASYNC communication
[:] Write to EPROM at f0:0000 ignored

<snip repeats>

[:] Write to EPROM at fe:0000 ignored
[:] Write to EPROM at fe:0001 ignored
[:peb:slot6:tipi] Closing connection
[:peb:slot6:tipi] Trying to connect to Raspberry Pi at 192.168.2.226:9901/tipi
[:peb:slot6:tipi] Connection established
[:peb:slot6:tipi] TIPI server offers ASYNC communication
[:peb:slot6:tipi] Stopping TIPI
Average speed: 99.91% (111 seconds)

 

269 

D:\mame>gmtipi.bat

D:\mame>mame genmod -window -oslog -bios 1.00 -peb:slot3 horizon -peb:slot6 tipi -conn rpi.192.168.2.226 -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -peb:slot8:hfdc:h2 generic -peb:slot8:hfdc:h3 generic -peb:slot8:hfdc:f3 525dd -peb:slot8:hfdc:f4 525dd -hard1 genos7boot.HD -hard2 Bootdisk2.HD -hard3 Bootdisk3.HD -flop1 DM1000SRC.dsk -flop2 DSDD2.hfe -flop3 DSDD3.dsk -flop4 DSDD4.dsk
[:maincpu] Variant = standard (with on-chip RAM), Overflow int = no check
[:peb] AMA/B/C address prefix set to 00000
[:peb] Slot 2 = :peb:slot2:memex
[:peb] Slot 3 = :peb:slot3:horizon
[:peb] Slot 4 = empty
[:peb] Slot 5 = empty
[:peb] Slot 6 = :peb:slot6:tipi
[:peb] Slot 7 = empty
[:peb] Slot 8 = :peb:slot8:hfdc
Fatal error: Device 5.25" double density floppy drive load failed: Unable to identify image file format

-----------------------------------------------------
Exception at EIP=00007ff789419c81 (std::unique_ptr<device_t, std::default_delete<device_t> > emu::detail::device_type_impl_base::create_driver<electron_state>(emu::detail::device_type_impl_base const&, machine_config const&, char const*, device_t*, unsigned int)+0x2f81): ACCESS VIOLATION
While attempting to read memory at 00000000000000d0
-----------------------------------------------------
RAX=00007ff78c344fd0 RBX=0000000000000000 RCX=0000025452560a10 RDX=000002544ff30000
RSI=0000025452560a10 RDI=0000000000000000 RBP=000000ba625f9ae0 RSP=000000ba625f9540
 R8=00000000ffffffff  R9=0000000000000001 R10=000002544ff30000 R11=000000ba625f9550
R12=000000ba625f9890 R13=00007ff78c1da040 R14=000000ba625f9980 R15=000000ba625f99a0
-----------------------------------------------------
Stack crawl:
  000000ba625f95e0: 00007ff789419c81 (std::unique_ptr<device_t, std::default_delete<device_t> > emu::detail::device_type_impl_base::create_driver<electron_state>(emu::detail::device_type_impl_base const&, machine_config const&, char const*, device_t*, unsigned int)+0x2f81)
  000000ba625f9620: 00007ff78981d0fb ((anonymous namespace)::firefox_state::firefox(machine_config&)+0x16ab)
  000000ba625f9660: 00007ff7898ef175 ((anonymous namespace)::skullxbo_state::skullxbo(machine_config&)+0x0285)
  000000ba625f97e0: 00007ff7898f83aa ((anonymous namespace)::skydiver_state::skydiver(machine_config&)+0x357a)
  000000ba625fedb0: 00007ff789f3e76f (cybiko_state::cybikoxt(machine_config&)+0x10bf)
  000000ba625ff1a0: 00007ff789fea5ac (deco156_state::hvysmsh_map(address_map&)+0x0afc)
  000000ba625ff480: 00007ff789feab9f (deco156_state::hvysmsh_map(address_map&)+0x10ef)
  000000ba625ff4e0: 00007ff789f397a7 (cybiko_state::cybikov1_debug_serial(machine_config&)+0x0127)
  000000ba625ff8a0: 00007ff78bdcc3df (luaopen_lfs+0x1acebef)
  000000ba625ff8f0: 00007ff7893812e9 (__tmainCRTStartup+0x0169)
  000000ba625ff920: 00007ff7893813f6 (__tmainCRTStartup+0x0276)
  000000ba625ff950: 00007ffe77d37374 (BaseThreadInitThunk+0x0014)
  000000ba625ff9d0: 00007ffe7805cc91 (RtlUserThreadStart+0x0021)

D:\mame>
 

 

[+mizapf]

Please remove the HFE disk image. I have to rewrite the HFE support.

[pjduplooy]

Hi.

 

I have problems with the new MAME (0.269).  Was the Linux version compiled against a newer libc and libstdc?  It does not work on my Debian 12 box.  Works on Ubuntu 24.04.  The last version usable is 0.265.  As workaround I run it an Ubuntu 24.04 Distrobox.

Edited September 2 by pjduplooy

[+mizapf]

Yes, I built it on Ubuntu 24.04. Can you build it on your Debian box?

[+mizapf]

11 hours ago, dhe said:

Fatal error: Device 5.25" double density floppy drive load failed: Unable to identify image file format

-----------------------------------------------------
Exception at EIP=00007ff789419c81 (std::unique_ptr<device_t, std::default_delete<device_t> > [...]
  000000ba625f9620: 00007ff78981d0fb ((anonymous namespace)::firefox_state::firefox(machine_config&)+0x16ab)

What's Firefox's business here?

 

The fatal error should terminate but not crash the emulator; I have to check that.

[pjduplooy]

Hi.

 

I will give it a go.  Is there build instructions somewhere?  Is mameprep part of the process?

 

Edit:  Found it on Ninermame

Edited September 2 by pjduplooy

[+dhe]

@mizapf - that worked.

 

 A couple of questions.

  1) Why do you have to re-write HFE support?

  2) Is there a readme that I should read, before running a new version?

 

Thank you for the help.

[+mizapf]

Did you notice that HFE could not write anymore? (https://www.ninermame.org/info/releases, release 0.242 on Apr 1, 2022)

 

I noticed that by chance when I tried to load one of the copy-protected disks (I think it was DiskAssembler), and it did not work anymore. I remembered that it once worked, so I checked the sources, just find that half of the code of hxchfe_dsk.cpp was removed by a MAME dev (without giving me any notice).

 

The reason was that people tried to create HFE disks inside MAME - you can do that in the File manager -, but this was a use case that I did not have in mind. I always assumed that there is a working HFE image (created by some external tool). Anyway, this action led to a crash of MAME, and since they did not know how to fix it, and I admittedly did not regularly check the MAMETesters site where this was reported, they removed it. Since I did not use HFE for some time, I noticed that change more than a year later.

 

I picked up the work on HFE three weeks ago, but I noticed that in the meantime, the format was greatly enhanced. It can now also handle GCR encodings (C64) and other recording formats. So the problem unfolded: Originally, I designed the HFE image format as generic, usable by all MAME systems, with a few supported recording formats (FM and MFM). Now with the new formats, thing become even more complicated: The format would either have to autodetect its own recording, or the developer would have to give this information on instantiation time. Detecting FM or MFM is not hard, but telling the dozens of other formats safely apart will probably be too difficult. That is, I will have to write a HFE class that serves as a base class from which several specialized variants can be subclassed, for example, a FM/MFM-HFE format.

 

What I did now was just to remove HFE from the list of generic image formats, not from the MAME source. It can be added explicitly to the computer system where needed, but I forgot to do that for our TI systems. Anyway, it only works half, and it also fails for the copy-protected disks, so not much is lost right now.

 

I'll certainly inform all of you once the format is usable again.