mizapf

I suppose your right arrow key works in general. You can check whether something was reconfigured in the user interface: Go to the OSD, "Input (general)" → "User Interface". There you should the attached screen. You can redefine "UI Right" by selecting it, pressing Del to remove the current mapping, Return to define a new one. Also, you can edit the cfg/ti99_4a.cfg file (or ti99_4ae for the European version): <?xml version="1.0"?> <!-- This file is autogenerated; comments and unknown tags will be stripped --> <mameconfig version="10"> <system name="ti99_4ae"> <input> <port tag=":ioport:peb:slot7:ide:MODE" type="DIPSWITCH" mask="3" defvalue="0" value="2" /> ... </input> </system> </mameconfig> (change the slot according to your configuration)

And if you don't let your machine program return to Editor/Assembler; if you do a BLWP @0 to exit, there is no need to save the GROM address.

When you are in this menu, you should normally be able to use the right arrow to change the setting. In this screenshot, you would have to hit right arrow twice to get to the TI setting. If your left arrow does not work, you will have to find out that issue first probably.

They are saved until you change the PEB card locations. If you mix cards from time to time, you should make a copy of the file cfg/ti99_4a.cfg. It contains all your DIP switch setting, key assignments, and configuration switches. Then you can replace that file when necessary.

As a short explanation, these settings are on the real card as well, as jumpers. The selection SRAM vs. RTC is intended for the RTC65271, which has a buffered on-chip RAM, so the selection "RTC" will map this RAM into the address space, and the card can bootstrap itself from this RTC memory. However, it does not make sense for all BQ chips. Second, I set the mode switch to off to avoid a hangup when the contents of the SRAM are invalid.

Yes, but this is HTTP(S), which requires a HTTP client, and not the ftplib.

I thought you set up a NNTP server on thekeep.net.

Here is the RPK; use a configuration like this: mame64 ti99_4a -ioport peb -ioport:peb:slot2 samsmem -ioport:peb:slot3 speech -cart texcaster.rpk texcaster.rpk

To better cover the scope, the description "Subforum for standalone non-4A systems with a 16 bit CPU belonging to the TMS99xxx processor family" should be changed. Maybe like this: "Subforum for non-4A systems based on the TMS99xx or TMS7xxx processor family, related to the TI-99/4A" "Subforum for TI-99/4A-related systems based on the TMS99xx or TMS7xxx processor family" The CC40 is clearly not a 99xx system but an 8-bit system. A good question is where to draw the line. The CC40 should be in, but also the more calculator-like TI-74 or TI-95? But then I would suggest to include the Geneve as well, as it matches that description.

And the CC40 is also based on the TMS7000.

If not, you may have to try http.client. WHtech's http server seems to be configured to deliver the directory content when you use a URL that points to a directory, so you should be able to load that page and parse it.

I'm getting an NNTP error "Access denied - you are not my news server" when I try to connect via Thunderbird.

The Rise of Usenet!

You have to use hard1, hard2, hard3 etc. (the same holds for all other media like flop1, flop2, ...). The problem is that the MAME core assigns this sequence of media to the devices that declare to be connected to this type, and there is (currently) no way to specify which device gets which one - possibly some legacy of the arcade origins of MAME. The cards in the PEB are initialized in sequence of their slots. When the IDE controller is initialized, it requests a medium of type "hard disk"; you have to provide that in the command line as "-hard ..." or "-hard1 ..." (if there is only one, you can omit the 1). When there is another card that requests such devices, it continues with "-hard2", "-hard3" etc. This has nothing to do with the "h1", "h2", "h3" connectors. The whole thing would be cleaner if we had to provide the path, but I am quite sure that not everyone would gladly agree if you had to write "-ioport:peb:slot8:hfdc:h1 harddisk1.hd" instead of "-hard1 harddisk1.hd".

@alanbeardGreat news! One point: How do I build TASM from the sources? Also, would you mind sending me the adf images? I could possibly use them in the Amiga emulation in MAME.

And you must plug the PEB itself into the I/O port.

Should be "-ioport peb -ioport:peb:slot8 bwg"

Concerning the issues with the parallel use of IDE and HFDC, mind that the "hardN" switches have no path specification. That is, they are assigned in order of initialization of the peripheral cards. The IDE defines one hard disk connector and picks hard1; then the HFDC gets hard2, hard3, hard4 (on h1, h2, h3).

Yes, you have to name it "exbas25". Or you change the contents of hash/ti99_cart.xml. Have a look at the element <software name="exbas25">. The name determines the name of the ZIP file.

The ZIP files must NOT be specified by path name. wrong: -cart some/path/cartridge.zip correct: -cart cartridge In contrast, the RPKs are specified by path name. To ensure that MAME finds the cartridges, the ZIP files must be stored in a folder that is part of the "rompath", specified in mame.ini. It is "roms" by default.

The Myarc disk controllers (DDCC-1 and HFDC) have a DIR subprogram in their DSR which just does that - this is why the DDCC-1 was my favorite controller. CALL DIR(disk#) provides a directory listing, but the ROM space was the limiting factor for the early controllers like the original TI controller. TI changed their strategy with the Hexbus peripheral system which allowed for devices that contained complex functions. For instance, the HX5102 has an integrated formatting routing.

CALL INIT seems to fail; this would normally mean that there is no memory expansion. At least that error message occurs when there is no 32K memory expansion.

Please check my web page https://www.mizapf.de/ti99/mame/changes You should definitely upgrade to the latest MAME version. I worked over the whole IDE stuff after 0.217.

a) I recommend to use one of the DSDD controllers (all except fot the tifdc). Always remember: Double density also means double speed. b) It could happen that one of these controllers accepts the uncommon geometry of the 800k disks. I would not count on it. It is not a matter of MAME supporting it, but of the DSR of the card. It is possible that you cannot use such an image in MAME until I write an emulation for the NanoPEB. c) @WhataKowinkydinkMAME does support the PC99 format. I fixed that issue after I noticed it.

When I implemented it in MAME and TIImageTool, I started to get creative and implemented a really flexible format which tried to autodetect the address marks and also filled in the proper CRC values instead of the pseudo F7 values ... ... just to learn some years later that PC99 rejected all these disks. The track dump format of PC99 is not as flexible as it seems, which is why I don't use this format in MAME and don't recommend it either. If we need a format that covers really weird stuff, there is still HFE.