Jump to content

mizapf

Members
  • Content Count

    4,543
  • Joined

  • Last visited

  • Days Won

    3

mizapf last won the day on August 31 2016

mizapf had the most liked content!

Community Reputation

3,683 Excellent

2 Followers

About mizapf

  • Rank
    River Patroller
  • Birthday 09/24/1969

Profile Information

  • Gender
    Male
  • Location
    Germany
  • Interests
    MAME, TIImageTool, Ninerpedia
    Linux advocate (openSUSE/KDE)

Recent Profile Visitors

17,426 profile views
  1. Yes, more like a simulation. For this serial interface, I implemented an input/output device in MAME that connects to the emulated RS232 and which sends data to a socket (and vice versa). I set up a line protocol that transmits the data byte-wise and also allows for transmitting configuration operations (e.g. set the baud rate). To make use of that serial data stream you need a TCP server that listens on the configured port and accesses the real serial device. This is included as the "serial bridge" inside my TIImageTool. It requires the RXTX Java library. Although control line changes are detected, a safe handshaking proved to be unfeasible because of the buffers in the network path and the buffered UART in the PC. Here is a thorough description; the class names are outdated, however. The principal function is still the same. https://www.ninerpedia.org/wiki/MESS_Serial_connection (I should add that I still use this serial connection between MAME and my real Geneve from time to time, and it works reliably up to 38400 Baud.)
  2. mizapf.eu and mizapf.de are the same IP address, but different virtual hosts.
  3. Please post your script here or the parametrized command line. I'll check. (Better: in the Raspi/MAME thread)
  4. That is not the correct URL; it should be https://www.mizapf.de/en/ti99/mame/mamereq (where did you get it that way?)
  5. Not your fault, it just means that the Gamebase should be updated to include the current MAME.
  6. This looks like a pre 0.145 MESS, with none of my works of the past eight (!) years.
  7. The p-System emulation in MAME uses disk images. Maybe you just install MAME in parallel and try which one suits you better. (Although some people seem to believe you have to decide for one emulation system, there is really no problem keeping all of them on your system.) There are some tools to transfer disk images to the real TI and back. One of the easiest ways could be the Lotharek/Gotek disk emulator.
  8. As I explained above, it is not really a question of preference. As a matter of fact, RPK is not the standard cartridge format of MAME, regardless of whether we consider it useful or not. The only reason it survived so long is that it has not bothered anyone else right now. As soon as it gets into conflict with some future MAME feature, I'll have a hard time to defend it. For that reason, I added the ZIP support some years ago, to be on the safe side at least for the old cartridges. It just needs to be enhanced to allow for homebrew stuff, and if we once have a solution for that, it should not be too difficult to convert the RPKs to ZIPs. As for the homebrew stuff of other systems, either the people found another solution, they don't care, or they edited their hash files; I don't know. I only know that no other MAME system is using it, since the code was moved many years ago into the ti99 subtree, and no other code includes it.
  9. Since we have several emulators here, where all the maintainers doubtlessly spent a lot of work, partly over many years, and those maintainers are active people in this forum, a question about "good" or "worse" or "better" is, I would say, difficult to answer, maybe even unfair. Please be more specific what you consider desirable for an emulation.
  10. You can use FTP, but there is a pseudo-anonymous login: user=anonymous pass="" (empty string, don't use quotes) This is not the proper anonymous login of FTP (which uses user=anonymous, [email protected]). For that reason, you cannot use FTP with Firefox or other browsers without entering the above authentication. FTP is still important, at least for uploading.
  11. By metadata, do you mean the meta-inf.xml or the layout.xml? The first one was intended to hold data about publisher, year, version, language etc. This one was never really used; instead, the ZIP cartridges have these metadata in the software list file that is delivered with MAME. If you want to have a look, this is the file that takes the role of the layout.xml and the meta-inf.xml: https://github.com/mamedev/mame/blob/master/hash/ti99_cart.xml As for the RPK future, the goal would be to have something like this software list file focused to this one cartridge, and it could then be stored inside the ZIP file. I suppose the reason why this is still not finished can be found in many larger projects: I brought up the topic lots of years ago. Someone said, hold it, I have a solution for that. But nothing changes. Another one said that the command line argument handling should generally be revisited, and that he had something at work right now, but after months or years you still don't hear a thing... The good thing is that the replacement of RPK is at priority MIN+1 or less. Since they are working, and since other computer systems or arcade machines just don't have that demand for homebrew cartridge implementation, no one really feels like moving. My concern is that one nice day, the core developers could decide on some freaky new feature for the command line which could make it impossible to keep the RPK loading, and then I am f***d because I am the only one that really needs it.
  12. BTW, the ZIP section on that page is really outdated; the ZIP format is now more advanced than the RPK. The page was last updated by me in April 2016; must have been around MAME 0.173 ... 50 releases back in the past.
  13. If I may shortly elaborate on that: RPK files are in fact ZIP archives, containing dumps of ROM and GROM space, metadata information (not used), and a layout file that says what the dump files actually are. The dump files do not need any special naming convention (like *c.bin), as all information comes from the layout file. The RPK files were designed to simplify the handling of cartridges; before, all dumps had to be mounted separately (e.g. three dumps for Extended Basic: GROM space, first ROM bank, second ROM bank). I decided not to call them "*.zip" so that people are not motivated to unpack them. (By the way, the same concept of non-proper zip files is used by LibreOffice or MS Office; try to unzip a DOCX file to see.)
×
×
  • Create New...