Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

mizapf

Members
 View Profile  See their activity

  • Content Count

    5,366

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by mizapf

  1. Posted

    Hmmm ... sorry if that does wipe out anything; I'm not aware of any such side-effect of QMC2. I can check that and give feedback to the QMC2 author.

     

    What was actually lost - the QMC2 configuration or the NVRAM files? You should try to run the emulation outside of QMC2 to check whether the NVRAM is still OK.

     

    It was actually intended as a reply to your question. The zip files are only selectable via the software list. Actually, as I wrote in my long description above, you do not provide a file name but the name of the cartridge. Within QMC2 this is done in the section for software list. You cannot put the zip file in the place of the RPK file.

  3. Posted

    Some explanations:

     

    The RPK files are cartridges which contain the memory dumps as files and another file (layout.xml) which informs the emulation which file belongs to which part of memory. This was designed mainly by me at times where the user had to install the dumps at the proper locations himself.

     

    RPK cartridges have to be installed by giving the path name of the file. That is, you would have to specify /home/michael/mess/carts/editor_assembler.rpk, just like a disk image file.

     

    The ZIP files are a more recent format (and have become the standard MAME/MESS cartridge format) which merely differ from the RPK files by not including the XML file, but only the dump files. The layout is defined inside MAME/MESS. The file name is also defined in that file, so the name of the cartridge zip file must exactly match the name in the internal file.

     

    Both formats have their pros and cons.

     

    RPK: You can have several different instances of a cartridges. For example, you could have two different MiniMemories. Since the memory contents are stored in a file in the nvram folder and not in the RPK, you could modify the layout.xml of one cartridge and change the backup file name. That way, either cartridge has its own saved memory without overwriting one another. Also, you can easily change the cartridge contents, in particular when there are new releases. RXB is such a case. Also, not all RPK features have been included in the zip file handling, in particular we do not have NVRAM definitions, which are required by cartridges like MiniMemory or SuperSpace. Finally, the names for RPKs are completely free to choose, while the zip files must not have names longer than 8 characters plus ".zip". Yes, I complained about that one, with minor success (actually, none).

     

    ZIP: The zip format is directly supported by the MAME core. In order to plug in a cartridge you have to specify the name of the cartridge, not the path name of the file. This may be more comfortable in many occasions (much less typing). For Editor/Assembler, the name is "editass". The good thing is that the MAME core can look up the cartridge in case you do not know the exact name, and it tries some fuzzy search:

     

     

    ./ti99 -cart edit

"edit" approximately matches the following
supported software items (best match first):

* Software list "ti99_cart" (TI-99/4A cartridges) matches:
editass           Editor/Assembler
edasseb           Editor Assembler 1987 / Easy Debugger 2.1
speeched          Speech Editor
edupack           Edu-Pack
pertest           Peripheral Diagnostic Module
alienadd          Alien Addition
earlyrd           Early Reading
addseq            Milliken Math Sequences - Addition
perrecdi          Personal Record Keeping (German/Italian)
readadv           Reading Adventures
readflt           Reading Flight
readtrl           Reading Trail
centipd           Centipede
escape            Escape
blackhl           Black Hole
burgerbd          Burger Builder

FATALERROR: Device TI-99 cartridge load (edit) failed: File not found

     

    One of the most important features of zip files are that you can verify the ROM contents. That is, the MAME core rejects cartridges that have modified contents, compared to the fingerprints inside the emulation. Of course, this is only an advantage from the conservation viewpoint; in case of "homebrew" software that is currently still being developed, some devs have proposed to be able to add the definitions as a separate XML file. Maybe I can convince them to use the RPK format for that. At least they seem to have understood my point that I do not plan to remove the RPK support now or in foreseeable future, since it does well what it is intended for.

     

    (I confess that I use the zip format increasingly often if the cartridge is actually supported by the zip format ... just for the sake of less typing.)

  4. Posted

     

    I think the main drawback to Linux when dealing with a large work force is the fact that most people still use Windows at home, are familiar with its apps (email, IE, Office etc...) and generally know their way around it to varying degrees. Linux on the other hand feels very unfamiliar to the uninitiated, particularly if one wanders away from the basic apps. In a work environment, you need to maximize efficiency, and there is no benefit to risking confusion among even a small percentage of the work force by using Linux when a perfectly good and familiar alternative exists.

     

    I agree with your analysis, but it also makes me deeply worried. This is - in my view - a proof that the idea of a market economy is flawed, in particular as soon as people do not (dare to) choose independently. When social factors come into play, there is no real selection according to market mechanisms.

     

    Imagine we were to design an OS that were to endanger Windows' prevalence. How must such an OS look/feel like to become popular on a large scale? I'm afraid the answer is: as soon as this OS perfectly looks and feels like Windows. Any kind of change, maybe for the better, is always in trouble of being rejected just for the reason of being different. People don't want to bother about how to use their computer.

     

    In the 90es I was a big OS/2 fan, while people were still trying to get their Windows 3.11 working. OS/2 did many things pretty differently, and it featured a very modern kind of user interface with object-oriented concepts. It was technically far ahead of Windows at that time (true 32 bit pre-emptive multitasking etc). What happened - people mainly ignored it and waited for Windows 95. The story continued while I changed to Linux at the end of the old millenium.

     

    To be fair, I think there is actually another chance to convince people for an alternative: as soon as they can use the same applications as on Windows. So Microsoft was very clever to not port their Office to Linux, and I guess they won't ever do that, or if they ever do, they've already given up Windows.

    • Like 2

  5. Posted

    MESS with the EVPC does a nice job with 80-column that I find highly readable. I think it's actually going to be my default setup from now on ;).

     

    Oh, that means I should better not add some blur for better "emulation experience"? :)

     

    Apart from that, the colors need some adjustment; the TMS9918 emulation is much closer to the real thing

    • Like 1

  7. Posted

    1. Including the Geneve - no, last time was for my diploma theses in 1994 when I used Fortran9640 to create plots for complex analysis. Maybe I did some TI-related text processing some more time. I use my Geneve nowadays for testing / comparing with the MESS emulations

     

    2. Linux PC (openSUSE), with Windows in a VirtualBox

     

    3. Most of the time desktop, laptop for my lectures, tablet while riding the train / lying in bed etc.

  8. Posted · Edited by mizapf

    OK, I thought all the cartridges would be loaded into the HSGPL in one go, so I did not know where I can keep some space for the Extended Basic or Editor/Assembler.

     

    Just tested with Extended Basic: LOAD loads and shows a menu of cartridges with A-MAZE-ING at A though to Zero-Zap at P, and when I press a button it says "loading" with different files, then it changes to the cartridge selection screen with "1 FOR RETURN TO GROM" and "2" with the selected game. When I press 1, the HSGPL master title screen reappears. 2 launches the game as expected.

     

    Seems to be as expected. This version of HSGPL is contained in MESS 0.153 that will be released tomorrow.

     

     

    EDIT: *sigh* Sorry, not everything is good. I just noticed that the GROM-only games are working well, but many of the GROM/ROM games do not start up. Also, the GRAM banks are still not fully working - I cannot do a transfer from a bank 0-f to 10 or 11 without messing up things. Transfers to other GROM banks are correctly working.

  10. Posted

    @gazoo: Good news, it seems as if I could clear all remaining bugs in the HSGPL. I wonder why they remained undiscovered till now (things like an inverted bank_enabled and so). The banks 0f, 10, 11 now work as well. Going to try your HSGPLMENU later ... it's 2:30 am here right now.

  11. Posted

    No, it's a bit more complicated ... :-)

     

    HSGPL banks 0-15 are GROM banks 0-15, but the next 8 ports are used to access the DSR Flashrom, then another 8 ports are used to access the ROM6 via GROM ports, and *then* we come to HSGPL banks 16 and 17 which are the RAM banks and thus correspond to GROM banks 32 and 33.

     

    There's a bit more broken here in the emulation. I'm not sure whether I'll make it till Monday when MESS 0.153 is scheduled...

  13. Posted

    Long ago(~1989) I wrote a tool named SPEECODER that was able to decode the LPC speech frames so that you could edit the frame parameters, copy and paste parts together (not in the brutal way of "Adding suffixes to speech words" in the Extended Basic manual), save them as BYTE lines for Assembly language or as DATA lines for merging to Extended Basic programs. If someone is interested I could upload a copy.

  15. Posted

    The MESS emulation of the HSGPL shows some weird behavior. I guess this means some deeper inspection.

     

    I noticed when I load a cartridge with ROMs in a bank, the ROMs are not shown as being set. Worse, they do not work until the emulation is stopped; when restarted, the ROMs work correctly. Example: I can load Extended Basic in bank 0, but it does not work before the emulation is stopped and restarted. And even then, the ROMs are still not reported in the overview page of the HSGPL. I recall this worked better some time ago.

     

    Stopping causes the flash rom to be written to the nvram file, and restarting reads it from the file again. Have to think about that ...

  17. Posted · Edited by mizapf

    I do not know of any GROM-based device that raised interrupts; GROMs may, however, slow down the CPU using the READY line.

     

    No, honestly, as I said in the other thread, I believe CLR R8 in GPLWS in the console is meaningless. It does not hurt, so it is not a bug in a proper sense, just a useless line. Maybe Heiner Martin was deceived by this code in the same way and believed that it clears the GROM search pointer, so he added this comment.

     

    Or let's turn it this way - they may have had something in mind with clearing the GROM search pointer, but it was obviously unneeded.

  18. Posted

    I already thought about porting TIImageTool to a native C++ application and use a cross-platform GUI system like Qt so that I can compile it for Linux, Windows, and Mac (just like MESS). Maybe this makes it easier for some people to install and run it. However, it will be a lot of work (143 classes), and I'd have to learn how to map Java Swing classes to Qt. I'm not sure whether and when to find enough time for that.

    • Like 1

  22. Posted

    Well, hmmm ... that's a real pity. You still get the class version error? I don't know what Apple did to Java, but this particular problem arose around 2009 or so (considering the date of the posts in forums), so I thought in the meantime, all platforms automatically have an updated Java.

     

    As for the openJDK, you do not need the latest release, a 1.6 or 1.5 should suffice. Maybe this allows you to keep your OS version.

     

     

     

    BTW, I always see these rumours about Java have security issues, making people wonder whether they should immediate uninstall it or check their computers. Java was shown to have some exploits when run inside browsers (for Applets). What we have here with my tool is completely unrelated to the Applet issue. When run as an application (as here), Java has the exact same level of security or non-security as any other application that runs natively. Sometimes I tend to believe someone took the opportunity to launch a campaign against Java, right after some (possibly) minor issues showed up.

  24. Posted

    To be more precise: If I understood you correctly, the file name of the file in your PC directory (which is in TIFILES format) is also the file name as seen in Classic99. That is, if we have something like C:\MYFILES\EDITASSM\ASSM1, the file ASSM1 is in TIFILES format and will appear as ASSM1 inside the TI emulation (if the EDITASSM directory is mounted as a disk).

     

    What happens if you store a file on the TI using lower case letters or characters like ?, \ or *? For that reason I thought that it makes more sense to get the file name from the TIFILES format and not be depending on the PC file system constraints.

     

    I really do not want to advocate or convince you of anything, I just wanted to clarify so that I don't falsely assume things here. :)

  25. Posted

    You cannot execute jar files directly; they must be passed to the Java runtime. Hence the invocation of java.

     

    The UnsupportedClassVersionException means your Java runtime is outdated. Could you add the output of "java -version"? I'd expect this is some Java runtime earlier than 1.5, maybe 1.4 or earlier. As I need some classes from Java 5 (JVM 1.5), you'll have to upgrade this Java runtime, or you cannot run TIImageTool on that machine.

     

    I usually try to add error messages to the program which are self-explanatory to some degree, but this happens before my code is loaded. ;-)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...